home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-pppext-lcpext-00.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
21KB
|
928 lines
Network Working Group Simpson
Internet Draft Daydreamer
expires in six months January 1992
PPP LCP Extensions
Status of this Memo
This memo is the product of the Point-to-Point Protocol Working Group
of the Internet Engineering Task Force (IETF). Comments on this memo
should be submitted to the ietf-ppp@ucdavis.edu mailing list.
Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. Internet Drafts are draft
documents valid for a maximum of six months. Internet Drafts may be
updated, replaced, or obsoleted by other documents at any time. It
is not appropriate to use Internet Drafts as reference material or to
cite them other than as a ``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links. PPP also defines an extensible Link Control Protocol.
This document defines several additional LCP features which have been
suggested over the past year.
Simpson expires in six months [Page i]
DRAFT PPP LCP extensions January 1992
1. Additional LCP Packets
The Packet format and basic facilities are already defined for LCP [1].
The most up-to-date values of the LCP Code field are specified in the
most recent "Assigned Numbers" RFC [2]. This document concerns the
following values:
13 Connect-Time
Simpson expires in six months [Page 1]
DRAFT PPP LCP extensions January 1992
1.1. Connect-Time
Description
This Code provides a mechanism for notifying the peer of the time
remaining in this session.
The nature of this information is advisory only. It is intended
that only one side of the connection will send this packet
(generally a "dial-in server"). The session is concluded by the
Terminate-Request packet.
Implementation Note: This notification is defined as a separate
LCP Code, rather than a Configuration-Option, in order that
changes and warning messages may occur dynamically during the
session, and that the information might be determined after
Authentication has occurred. Typically, this packet is sent at
the beginning of a session, and at regular intervals throughout
the session, particularly near the end of the session.
A summary of the Connect-Time packet format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds-Remaining |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
13 for Connect-Time
Identifier
The Identifier field is one octet and is for use by the Connect-
Time transmitter.
Length
>= 12
Simpson expires in six months [Page 2]
DRAFT PPP LCP extensions January 1992
Seconds-Remaining
The Seconds-Remaining field is four octets and indicates the
number of integral seconds remaining in this session. This 32 bit
unsigned value is sent most significant octet first. A value of
0xffffffff (all ones) represents no timeout, or "forever".
Message
The Message field is zero or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain displayable ASCII characters 32 through
126 decimal. Mechanisms for extension to other character sets are
the topic of future research. The size is determined from the
Length field.
Simpson expires in six months [Page 3]
DRAFT PPP LCP extensions January 1992
2. Additional LCP Configuration Options
The Configuration Option format and basic options are already defined
for LCP [1].
The most up-to-date values of the LCP Option Type field are specified in
the most recent "Assigned Numbers" RFC [2]. This document concerns the
following values:
9 FCS-Alternatives
10 Self-Describing-Pad
13 Callback
Simpson expires in six months [Page 4]
DRAFT PPP LCP extensions January 1992
2.1. FCS-Alternatives
Description
This Configuration Option provides a way for an implementation to
specify another FCS format to be sent by the peer, or to negotiate
away the FCS altogether.
This option is negotiated separately in each direction. However,
it is not required that an implementation be capable of
concurrently generating a different FCS on each side of the link.
More than one FCS Option MAY be present in the same Configure-
Request, and any remaining FCS Options are Ack'd together. That
is, if the implementations agree, each packet may have a different
FCS.
The negotiated FCS values take effect only during Authentication
and Network-Layer Protocol phases. Packets sent during any other
phase MUST contain the 16-bit FCS.
The link can be subject to loss of state, and the LCP can re-
negotiate at any time. When the LCP begins renegotiation, it is
recommended that the LCP Configure-Request packet be sent with the
last negotiated FCS, followed by another LCP Configure-Request
packet with the 16-bit FCS. On receipt of a LCP Configure-Request
or Terminate-Request packet, the implementation MUST change to the
16-bit FCS for both transmission and reception.
The null FCS SHOULD only be used for those network-layer protocols
which have an end-to-end checksum available, such as TCP/IP, or
UDP/IP with the checksum enabled. That is, the null FCS option
SHOULD be negotiated together with another non-null FCS option in
a heterogeneous environment.
When an extraneous FCS is provided, any extra octets will appear
to be padding. Therefore, the null FCS option MUST NOT be used
with the Self-Describing-Pad Configuration Option (described
below).
When a configuration (LCP or NCP) or authentication packet is
sent, a FCS MUST be included. When a configuration (LCP or NCP)
or authentication packet is received, the FCS MUST be verified.
Simpson expires in six months [Page 5]
DRAFT PPP LCP extensions January 1992
A summary of the FCS-Alternatives Configuration Option format is
shown below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
9
Length
3
FCS
This field specifies the kind of FCS to be used on the link.
0 no FCS
16 16-bit FCS (default)
32 32-bit FCS
Simpson expires in six months [Page 6]
DRAFT PPP LCP extensions January 1992
2.2. Self-Describing-Pad
Description
This Configuration Option provides a way for an implementation to
indicate to the peer that it understands self-describing pads when
padding is added to the PPP Information field. This option is
most likely to be used when network-layer protocols, particularly
compression protocols, are configured which require detection and
removal of any trailing pads. Such protocols are identified in
thier respective NCP documents.
If the option is Rejected, the peer MUST NOT add padding to such
protocols, but MAY add padding to other protocols.
If the option is Ack'd, the peer MUST add at least one octet of
self-describing pad to such protocols, but is not required to add
unnecessary padding to other protocols.
Implementation Notes: This is defined so that the Reject
handles either case where the peer does not generate self-
describing pads; when it does not understand the option, or
when it never generates pads.
While some implementations might only be capable of adding
padding to every protocol or not adding padding to any
protocol, by design the receiver need not examine protocols
which do not need the pads stripped.
To avoid unnecessary configuration handshakes, an
implementation which generates padding, and has a protocol
configured which requires the padding to be known, SHOULD
include this Option in its Configure-Request, and SHOULD
Configure-Nak with this Option when it is not present in the
peer's Request.
Each octet of self-describing pad contains the index of that
octet; that is, three pad octets would contain the values 1, 2, 3.
After removing the FCS, the final pad octet contains the number of
pad octets to remove.
Implementation Note: If any of the pad octets contain an
incorrect index value, the entire frame SHOULD be silently
discarded. This is intended to prevent confusion in an
environment which understands more than one FCS, but might not
be necessary in robust implementations.
Simpson expires in six months [Page 7]
DRAFT PPP LCP extensions January 1992
A summary of the Self-Describing-Pad Configuration Option format is
shown below. The fields are transmitted from left to right.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
10
Length
2
Simpson expires in six months [Page 8]
DRAFT PPP LCP extensions January 1992
2.3. Callback
Description
This Configuration Option provides a way for an implementation to
request a dial-up peer to call back. This option might be used
for many diverse purposes, such as perceived security or savings
on toll charges.
When callback is successfully negotiated, the Authentication phase
proceeds directly to Termination phase.
Implementation Note: A peer which agrees to this option SHOULD
request the Authentication-Protocol Configuration Option. The
user information learned during authentication can be used to
determine the user location, or to limit a user to certain
locations, or merely to determine who to bill for the service.
A summary of the Callback Option format is shown below. The fields
are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Operation | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
13
Length
>= 3
Operation
The Operation field is one octet and indicates the contents of the
Message field.
0 location is determined by user authentication
1 telephone number
2 location identifier
Simpson expires in six months [Page 9]
DRAFT PPP LCP extensions January 1992
Message
The Message field is zero or more octets, and its contents are
determined by the Operation field. The size is determined from the
Length field.
Simpson expires in six months [Page 10]
DRAFT PPP LCP extensions January 1992
A. Fast Frame Check Sequence (FCS) Implementation
A.1. 32-bit FCS Computation Method
The following code provides a table lookup computation for
calculating the 32-bit Frame Check Sequence as data arrives at the
interface.
/*
* u32 represents an unsigned 32-bit number. Adjust the typedef for
* your hardware.
*/
typedef unsigned long u32;
static u32 fcstab_32[256] =
{
0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
Simpson expires in six months [Page 11]
DRAFT PPP LCP extensions January 1992
0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
};
#define PPP_INITFCS32 0xffffffff /* Initial FCS value */
#define PPP_GOODFCS32 0xfebb20e3 /* Good final FCS value */
/*
* Calculate a new FCS given the current FCS and the new data.
*/
u32 pppfcs32(fcs, cp, len)
register u32 fcs;
register unsigned char *cp;
register int len;
{
ASSERT(sizeof (u32) == 4);
ASSERT(((u32) -1) > 0);
while (len--)
Simpson expires in six months [Page 12]
DRAFT PPP LCP extensions January 1992
fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
return (fcs);
}
main()
{
int len;
u32 fcs;
unsigned char buf[10];
fcs = PPP_INITFCS32;
while ((len = read(0, buf, sizeof buf)) > 0)
fcs = pppfcs32(fcs, buf, len);
printf("0x%08X0, fcs);
exit(0);
}
Simpson expires in six months [Page 13]
DRAFT PPP LCP extensions January 1992
Security Considerations
Security issues are not discussed in this memo.
References
[1] Simpson, W.A., "The Point-to-Point Protocol (PPP)", RFC 1331,
May 1992.
[2] Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC 1340,
July 1992.
Acknowledgments
Some of the original text for FCS-Alternatives was provided by Arthur
Harvey (then of DEC). The null FCS was requested by Peter Honeyman
(UMich). The 32-bit FCS example code was provided by Karl Fox
(Morning Star Technologies).
The Self-Describing-Pad was suggested and named by Fred Baker (ACC).
The Connect-Time feature was suggested by Brad Parker (then of
Cayman).
Chair's Address
The working group can be contacted via the current chair:
Brian Lloyd
B.P. Lloyd & Associates, Inc.
3420 Sudbury Road
Cameron Park, California 95682
Phone: (916) 676-1147
EMail: brian@lloyd.com
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
Simpson expires in six months [Page 14]
DRAFT PPP LCP extensions January 1992
P O Box 6205
East Lansing, MI 48826-6205
EMail: Bill.Simpson@um.cc.umich.edu
Simpson expires in six months [Page 15]
DRAFT PPP LCP extensions January 1992
Table of Contents
1. Additional LCP Packets ................................ 1
1.1 Connect-Time .................................... 2
2. Additional LCP Configuration Options .................. 4
2.1 FCS-Alternatives ................................ 5
2.2 Self-Describing-Pad ............................. 7
2.3 Callback ........................................ 9
APPENDICES ................................................... 11
A. Fast Frame Check Sequence (FCS) Implementation ........ 11
A.1 32-bit FCS Computation Method ................... 11
SECURITY CONSIDERATIONS ...................................... 14
REFERENCES ................................................... 14
ACKNOWLEDGEMENTS ............................................. 14
CHAIR'S ADDRESS .............................................. 14
AUTHOR'S ADDRESS ............................................. 14